IBIS Macromodel Task Group Meeting date: 24 May 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Luis had joined the ATM meetings previously when he was with ANSYS. Arpad asked him to briefly reintroduce himself in his new role with IBM. Luis said he is working with the signal integrity team for the OpenPOWER Consortium, and that they will be producing IBIS-AMI models for their customers. ------------- Review of ARs: - Ambrish to send the latest BIRD 147 draft to Bob and Walter, as requested. - Done. - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Dan: Motion to approve the minutes. - Ambrish: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: [Pin Reference] BIRD Draft: - Arpad: We did discuss this last week in Walter's absence. - Were you able to follow that discussion in the minutes, Walter? - Walter: Yes, I kept up with the minutes. - My response to last week's discussion is that there are two distinct issues. - 1. There's just a shift in voltage for a device under test. - What's connected to the gc_ref is not 0V, but some non-zero voltage relative to the simulator's node 0. - How do you adjust the value of the voltage at the I/O pad in order to compare that correctly with thresholds in the IBIS file (e.g. Vinl)? - This would be the oft discussed case of VSS=1000V and VDD=1005V and the buffer should still work fine and the threshold should be 1002.5V. - 2. A device under test has 0V for its [GND Clamp Reference] and 5V for its [POWER Clamp Reference], but at simulation time the device in action sees a 6V difference between pc_ref and gc_ref. How should the thresholds be adjusted in that scenario? - [Receiver Thresholds] offered one way to deal with that. - Bob added a bunch of stuff to draft 3 of the BIRD to deal with this second issue, but it's a separate issue. - I think the way to deal with this would be to add a "technology" keyword with values like CMOS, TTL, ECL, PECL, etc. - We could add rules for each technology that specify how thresholds change. - Arpad: I think the original purpose of this BIRD draft was to help the Friday editorial meetings with their "ground" problems. - I understand this second issue seems like mission creep. - I would suggest a minimalist approach. Let us only cover what is needed for the editorial task group, but do it in such a way that we can expand upon it at a later time. - Walter: I don't think editorial is waiting on it. - I think they are expecting something like this [Pin Reference] BIRD to deal with these issues. - I would like to defer to the editorial group and see what they need. - Mike L.: This is a new keyword. - It would not have wide spread impact. - It won't hurt the editorial group if it doesn't come along until later. - Arpad: If the editorial work has this BIRD as a dependency, can they move forward? - What if this BIRD fails to be approved later? - Bob: I have a slightly different view than was presented here. - This group might be the better group to resolve some technical issues we haven't really resolved. - But I don't think this is holding up editorial. - Walter: Motion to table this BIRD here. - Dan: Second. - Arpad: Anyone opposed? [none] SPI 2016 report: [Walter asked to talk about SPI briefly] - Walter: - About 110 registered participants. - Mostly from Europe, perhaps 15 or 20 from Asia. - Several interesting papers related to IBIS I/O methodology. - Interesting and different approaches to our current I/V and v(t) Models. - One with v(t) tables but using 3 columns per corner. - One that was not table driven at all. - Some were admittedly science projects not ready for prime time. - My response to everyone was that they were all interesting approaches, but it is going to be very hard to get something through IBIS if EDA vendors will have to adopt something different than the existing K(t) methodology. - My suggestion to them was that rather than come up with a different table driven scheme where the EDA tools have to figure it out, perhaps we should come up with a .dll interface with the [External Model]. The .dll could even read tables, but I was just imagining how tough it would be to get some of these new methodologies through IBIS. - I also had conversations with a number of people on package models and their particular methods for doing power integrity. - There was certainly no consensus on one right way to do it. - I did come away convinced that the approach we are taking with the interconnect task group would satisfy the needs of all of their different power integrity methodologies. - Bob: Could you elaborate on the different power integrity approaches? - Walter: It's not uncommon that they would have separate power and data models. - The most complicated models lumped all of the grounds at the IC together and all the Pins together. So you could not have nodes per pin, it was nodes per each of what we call signal_name. - Some used SPICE models for the power and SPICE models for the interconnect and a totally different methodology for coupling the two. - Some approaches said, "it's just an impedance problem, you find out the impedance of the board and that's the impedance requirement for the package." - Some simulations took days. Some used noise budgets. There were lots of research projects. - Bob: Many of these are PhD students presenting, and we've kept in touch with many of them over many years. - Walter: Some given by PhD students, some by professors, one by Intel. - It was varied, not all academic. - Keysight gave a nice boot camp on power and signal integrity. - All the papers are published and one can read them. - Arpad: Walter, you mentioned something about Touchstone v2.0 in one of your email reports. Can you elaborate? - Walter: I am on the IEEE SA - P370 group, which is dealing with standards for s-parameter data measurements. - Several people on that committee happened to be at SPI. - When I mentioned Touchstone v2.0 I got some sour responses from people. - I suggested that we document some of the things they were doing with respect to quality of s-parameter data and gather some of them into an enhanced Touchstone v2.0, and they said, "Don't even bother, no one wants to touch Touchstone v2.0 with a ten-foot pole." - They said that "no tools read it and no tools write it." Obviously "no" is an overstatement, but there are so many internal, non-commercial tools people use that parse Touchstone files but don't support v2.0 that it is just unacceptable to the industry. - The only thing Touchstone v2.0 has that addressed a real need for people was per port impedance. If that was all that had been added it might have been adopted more widely. - But something as simple as removing the requirement for .sNp as the file extension was a deal breaker because so many tools relied on it. - Feedback I got was that they would like IBIS to do something, but don't change the Touchstone format. Leave Touchstone v1.0 as it is. Perhaps add one change for impedance per port. Perhaps define a side file that will define the near end, far end, and differential pairs without complicating the Touchstone file. - I have heard about, but not personally seen, the existence of one Touchstone v2.0 file. - Arpad: If Touchstone v2.0 does more than they want, why can't they just use part of it? - Walter: It's the whole structure. To use it at all you need to add in a bunch of new parts that break existing readers. C_Comp Improvements: - Discussion: Randy said he had recently reviewed the most recent draft, which was almost a year old. He said he needed to make some updates based on new decisions that had been made for the interconnect BIRD. He said he would update it and present it to the group at a future meeting. - New Redriver Flow: - Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 5] - I've updated the parameters according to the discussion we had in the meeting two weeks ago. - [Slide 12 - New Reserved Parameters] - Last time we talked about changing back to a two parameter approach because people didn't like the bi-directional parameter approach. - Two parameters: - Support_Proposed_Flow - Rx parameter, Info, Boolean, default=false - This parameter tells the simulator whether the Rx model supports the proposed flow. - Use_Proposed_Flow - Rx parameter, In, Boolean, default=false. - This parameter tells the model if the EDA tool is using the 6.1 flow or the new proposed flow. - These parameter names are not finalized. - [Slide 13 - contains a truth table for Parameter settings] - If Support_Proposed_Flow is false: - Tool and model must use 6.1 flow. - Tool cannot set Use_Proposed_Flow to true (illegal). - If Support_Proposed_Flow is true: - Simulator can still set Use_Proposed_Flow to false to use the old 6.1 flow. - Simulator can set Use_Proposed_Flow to true and then the tool and model will use the new proposed flow. - Discussion: Fangyi asked the group if we should require a model that supports the new flow to also support the old flow. Mike suggested that the question amounted to weighing the work imposed on the model maker for mandatory support of the old flow vs. the potential reputation issues for IBIS-AMI if we allowed a new class of models (new proposed flow only) that simply wouldn't work with any older tools. Walter said that he was fine with going to a two parameter approach, but that we should require models to support the old flow. He said that it should be easy for a model maker supporting the new flow to also support the old flow. Fangyi agreed that it should not be a big deal for a model that will support the new flow to also support the old flow. Arpad said that if that were true then we should make support for the old flow mandatory. No one in the group disagreed with the decision to keep support for the old flow mandatory. Arpad did raise the question of how long the spec would make support for the old flow mandatory. Curtis said that since we have the AMI_version parameter, we could wait until a future revision and decide to deprecate it then. Fangyi agreed. Walter said he thought we probably never would or should deprecate it. Bob suggested that we should come up with better names than "new" (proposed) and "old" (6.1) flow. Mike agreed that the sooner we came up with the final names the better. Mike noted that we had previously discussed this in the context of DFE, and he had wondered if we could come up with a more general category. He suggested we might use terms like a "one impulse response" flow and a "two impulse response" flow. - Michael M.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 31 May 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives